7장. 파인튜닝

파인튜닝은 모델의 가중치를 직접 업데이트해 특정 작업에 맞게 조정하는 과정이다. 메모리 병목이 이 분야 전체를 관통하는 핵심 제약이며, 파라미터 효율적 파인튜닝(PEFT)과 양자화가 그 해법으로 부상했다. '언제 파인튜닝을 하고 언제 RAG를 써야 하는가'라는 질문에 대한 답은 오류의 원인이 정보 부족(→ RAG)인지, 행동 방식의 문제(→ 파인튜닝)인지로 갈린다.

출처 — Chip Huyen, 『AI 엔지니어링』 한국어판, 7장 (pp. 364-425). 아래 모델명·수치는 모두 책 원문 인용이며 역사적 사실 기록 목적이다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 파인튜닝이 필요한 경우와 RAG를 사용해야 하는 경우를 오류 원인으로 구분할 수 있다.
• 메모리 제약 환경에서 PEFT(LoRA, QLoRA)와 양자화 기법을 선택해 적용할 수 있다.
• 저랭크 분해 원리로 LoRA가 추론 지연을 증가시키지 않으면서 파라미터 효율성을 달성하는 방식을 설명할 수 있다.
• 파인튜닝 데이터 크기와 모델 규모에 따라 전체 파인튜닝, PEFT, 모델 병합 중 최적의 전략을 선택할 수 있다.
• 학습/검증 손실 곡선을 분석해 하이퍼파라미터를 조정하고 정렬 세금을 측정할 수 있다.

전체 흐름도

이 장의 핵심은 "데이터를 준비하고, 메모리를 절약하면서 모델을 학습시키고, 결과를 평가해 배포하는" 파인튜닝 전 과정이다.

[ 오류 원인 분류 ]
      │  정보 부족(사실 오류)         행동 방식 문제(형식·안전성)
      ▼                              ▼
[ RAG 우선 검토 ]              [ 파인튜닝 검토 ]
      │                              │
      └──────────────┬───────────────┘
                     ▼
         [ 개발 순서 결정 ]
         (1) 프롬프트 엔지니어링
         (2) Few-shot 예시 추가
         (3) 단순 키워드 기반 RAG
         (4a) 고급 임베딩 기반 RAG
         (4b) 파인튜닝
         (5)  RAG + 파인튜닝 조합
                     │
                     ▼
         [ 데이터 준비 ]
         (입력, 출력) 쌍 수집 / 주석
         SFT / 선호도 / 도메인 적응
                     │
                     ▼
         [ 베이스 모델 선택 ]
         저비용 검증 → 중간급 탐색 → 강한 모델 최적화
                     │
         ┌───────────┴───────────┐
         ▼                       ▼
[ 전체 파인튜닝 ]          [ PEFT (LoRA / QLoRA) ]
모든 파라미터 업데이트       저랭크 행렬 A·B 만 학습
메모리 대규모 필요           소비자용 GPU 에서도 가능
                     │
                     ▼
         [ 양자화 선택 ]
         PTQ (학습 후) — 가장 간단
         QAT (학습 중) — 더 높은 품질
         비트 수: FP32 > FP16/BF16 > INT8 > INT4
                     │
                     ▼
         [ 모델 병합 (선택) ]
         선형 결합 / SLERP / 레이어 쌓기 / 연결
         가지치기(TIES·DARE) 후 병합
                     │
                     ▼
         [ 서빙 방식 결정 ]
         어댑터 병합(지연 없음) vs 멀티 LoRA(공간 절약)
                     │
                     ▼
         [ 평가 / 모니터링 ]
         학습·검증 손실 곡선, 정렬 세금 측정
         다른 작업 성능 회귀 여부 확인

0. 사전 필수 용어

참고 — 이 장은 ML 기초(역전파, 옵티마이저, 손실 함수)를 알고 있다고 가정한다. 처음 접한다면 책의 깃허브 저장소(https://github.com/chiphuyen/aie-book)에 정리된 참고 자료를 먼저 보는 것이 좋다.

• 지도 파인튜닝(SFT, Supervised Fine-Tuning) — (입력, 출력) 쌍으로 구성된 주석 데이터로 모델을 추가 학습하는 방식. 사전 학습 모델이 가진 능력을 특정 작업 방향으로 '표면으로 끌어올리는' 과정이다.
• 인필링 파인튜닝(Infilling Fine-Tuning) — 자기회귀 모델을 빈칸 채우기(마스크 예측) 방식으로 학습시키는 기법. 코드 디버깅·텍스트 편집에 유용하며, 특수 형식 토큰을 활용해 자기회귀 모델도 지원할 수 있다.
• 지속적 사전 학습(Continued Pre-Training) — 비싼 주석 데이터 없이 관련 도메인 텍스트로 자기지도 학습을 먼저 수행하는 방식. 법률 문서, 의료 기록, 특정 언어 텍스트 등으로 도메인 적응을 진행한다.
• 파라미터 효율적 파인튜닝(PEFT, Parameter-Efficient Fine-Tuning) — 전체 가중치가 아닌 일부 파라미터만 학습해 메모리를 줄이는 기법군. 어댑터 기반(LoRA 등)과 소프트 프롬프트 기반으로 나뉜다.
• LoRA(Low-Rank Adaptation) — 가중치 행렬을 두 개의 저랭크 행렬로 분해해 그 두 행렬만 학습하는 어댑터 기반 PEFT 기법. 추론 전에 원본 가중치와 병합하면 추론 지연 시간 증가 없이 배포 가능하다.
• 양자화(Quantization) — 모델 가중치나 활성화를 더 낮은 비트 형식(FP32 → FP16 → INT8 → INT4)으로 변환해 메모리를 줄이는 기법. 학습 후 양자화(PTQ)와 양자화 인식 학습(QAT)으로 나뉜다.
• 모델 병합(Model Merging) — 파인튜닝된 여러 모델의 가중치를 결합해 단일 모델로 만드는 기법. 합산(선형 결합, SLERP), 레이어 쌓기, 연결 세 가지 방식이 있다.
• 정렬 세금(Alignment Tax) — 특정 작업에 파인튜닝하면 그 작업 성능이 향상되지만 다른 작업에서는 오히려 성능이 저하되는 현상 (Bai et al., 2020).
• 내재적 차원(Intrinsic Dimension) — 모델이 실제로 표현하는 유효 차원 수. 사전 학습이 자연스럽게 모델의 내재적 차원을 줄이며, 더 큰 모델일수록 사전 학습 후 더 낮은 내재적 차원을 갖는 경향이 있다.

1. 파인튜닝 개요 — 전이 학습의 한 형태

파인튜닝은 전이 학습의 한 방법이다. 전이 학습은 1976년 보지노프스키(Bozinovski)와 풀고시(Fulgosi)가 처음 제안한 개념으로, 한 작업에서 얻은 지식을 새롭지만 관련된 작업에 활용해 학습 속도를 높이는 데 중점을 둔다. 피아노 칠 줄 알면 다른 악기를 더 쉽게 배울 수 있는 것과 같은 원리다.

전이 학습의 초기 대규모 성공 사례. 구글의 다국어 번역 시스템(Johnson et al., 2016)이 있다. 이 모델은 포르투갈어-영어 및 영어-스페인어 번역에서의 지식을 전이해, 학습 데이터에 포르투갈어-스페인어 예시가 없었음에도 포르투갈어를 스페인어로 번역할 수 있었다.

LLM에서의 전이 학습. 사전 학습 모델은 텍스트 완성(데이터가 풍부한 작업)에서 지식을 쌓고, 이를 법률 질의응답·Text-to-SQL 변환 같이 데이터가 적은 전문 작업에 전이한다. 전이 학습은 표본 효율성(sample efficiency)을 높여, 처음부터 학습하면 수백만 개가 필요한 예시를 파인튜닝으로는 수백 개만으로 충분하게 만든다.

InstructGPT 논문(OpenAI, 2022)의 관점: 파인튜닝을 모델이 이미 갖고 있지만 사용자가 프롬프트만으로는 끌어내기 어려운 능력을 활용 가능하게 만드는 것으로 볼 수 있다.

파인튜닝의 유형. 목적과 방식에 따라 여러 유형이 있다.

참고 — 2장에서 다룬 SFT와 선호도 파인튜닝은 모델 개발자가 모델 출시 전에 적용하는 사후 학습의 일환이다. 이 장에서는 애플리케이션 개발자가 출시된 모델을 자신의 사용 사례에 맞게 추가로 조정하는 관점에서 파인튜닝을 다룬다.

실제 사례 — 코드 라마(Code Llama, Rozière et al., 2024). 라마 2 파운데이션 모델에서 코드 학습(500B 토큰), 지시 파인튜닝(5B), 코드 완성 학습(20B), 롱 컨텍스트 파인튜닝(20B) 등 여러 파인튜닝 기법을 조합해 코드라마-Instruct, 코드라마-파이썬 등 다양한 파생 모델을 개발했다.

2. 파인튜닝이 필요한 경우

파인튜닝의 주요 목적은 일반 능력과 특정 작업 수행 능력을 함께 향상시키는 데 있다.

잘못된 예 — 파인튜닝이 필요하지 않을 때 무작정 시작하는 경우:

상황: 모델이 고객 질의에 제대로 응답하지 못함
잘못된 접근: 즉시 파인튜닝 데이터 수집 시작
올바른 접근: 먼저 프롬프트를 체계적으로 실험하고
             예시(few-shot)를 추가해 충분히 테스트한다
             → 많은 경우 프롬프트 품질 개선만으로 충분함

올바른 예 — 파인튜닝이 실제로 필요한 경우:

상황: 덜 흔한 SQL 문법(고객 맞춤 쿼리)에서 모델이 일관되게 실패
또는: JSON/YAML 출력 형식을 일관되게 유지해야 하는 시맨틱 파싱
또는: CEO를 항상 남성으로 지정하는 편향 완화 필요
→ 해당 데이터로 파인튜닝하면 효과적임

파인튜닝을 해야 하는 이유:

• 특정 작업(덜 흔한 SQL 문법, 커스텀 쿼리)에서 범용 모델이 실패할 때
• JSON·YAML 같은 특정 출력 형식을 일관되게 준수해야 할 때
• 편향 완화: CEO를 항상 남성으로 지정하는 모델에 여성 CEO 데이터로 파인튜닝하면 편향 감소 (Carimella et al., 2022)
• 지식 증류: 큰 모델이 생성한 데이터로 작은 모델을 학습시켜 큰 모델처럼 작동하게 함 (예: Grammarly의 Flan-T5가 텍스트 편집에서 더 큰 범용 모델보다 우수한 성능, 단 82,000개 예시 사용)
• 오픈 소스 커뮤니티가 다양한 크기의 고품질 모델을 계속 출시하면서 파인튜닝 가능한 경쟁력 있는 베이스 모델의 선택지가 크게 늘어남

파인튜닝을 하지 말아야 하는 이유:

• 프롬프트와 컨텍스트도 파인튜닝과 비슷한 효과를 낼 때가 많음 (프롬프트 캐싱 도입 후 토큰 최적화 장점도 감소)
• 정렬 세금(alignment tax): 특정 작업 파인튜닝 시 다른 작업 성능 저하
• 초기 투자 부담: 주석 데이터 수집, 모델 학습 지식, 파인튜닝된 모델 서빙과 모니터링
• 새로운 베이스 모델이 파인튜닝한 모델보다 더 나아질 수 있어 지속적인 유지보수 결정 필요
• 실험 시작 단계라면 먼저 프롬프트 엔지니어링을 충분히 시도하고 그 다음에 파인튜닝을 고려

도메인 특화 모델 주의. 블룸버그GPT(금융 특화, 500억 파라미터, A100 GPU 130만 시간, 컴퓨팅 비용 130만~260만 달러)가 같은 달 출시된 강력한 범용 모델에 HotpotQA(87.15 vs 75.07), 금융 감정 분석(76.48 vs 43.41) 등 다양한 금융 벤치마크에서 크게 뒤진 사례가 있다 (원문 인용 — Wu et al., 2023; Lee et al., 2023). 범용 모델이 점점 강해지면서 도메인 특화 모델보다 더 나은 성능을 보이는 경우가 많다.

3. 파인튜닝과 RAG — 오류의 원인이 결정한다

파인튜닝과 RAG 중 무엇을 선택할지는 모델 오류의 원인이 무엇이냐에 달려있다.

핵심 원칙: 파인튜닝은 형식을 위한 것이고, RAG는 사실을 위한 것이다.

잘못된 예 — 오류 원인 분류 없이 선택하는 경우:

상황: 사내 문서 질의응답 시스템에서 모델이 잘못된 답변 생성
잘못된 접근: "모델이 못하니까 파인튜닝하자"
올바른 접근: 오류 원인 분석
   → 모델이 사내 문서를 모른다 = 정보 부족 → RAG 먼저
   → 모델의 출력 형식이 잘못됨 = 행동 방식 문제 → 파인튜닝 고려

올바른 예 — 오류 유형별 대응:

정보 부족 오류 (→ RAG):
- 비공개 내부 데이터를 모르는 경우
- 지식 기준 날짜 이후 정보가 필요한 경우
  예) 테일러 스위프트 정규 앨범 수 질의 → 최신 앨범이 지식 기준 이후 발매됨

행동 방식 문제 (→ 파인튜닝):
- 사실은 맞지만 요청 작업과 무관한 내용 생성
- HTML 코드가 제대로 작동하지 않는 경우
- 시맨틱 파싱(자연어 → JSON/SQL) 형식 미준수
- 덜 유명한 도구의 특수 언어나 복잡한 구문 처리

Ovadia et al. (2024) 연구 — 시사 문제 질의응답:

기본 모델을 사용한 RAG가 파인튜닝된 모델보다 더 나은 결과를 냈다. 파인튜닝이 특정 작업 성능을 높이지만 다른 영역에서는 오히려 성능이 저하될 수 있음을 보여준다.

RAG와 파인튜닝의 결합 효과. 파인튜닝된 모델에 RAG를 추가하면 MMLU 벤치마크에서 43%의 시나리오에서 성능이 향상됐다. 단, 나머지 57%에서는 파인튜닝+RAG가 RAG만 단독으로 쓰는 것보다 어떤 성능 개선도 가져오지 못했다.

개발 흐름의 권장 순서 (그림 7-3 기반):

1. 프롬프트 엔지니어링 (모범 사례 + 버전 관리)
2. 예시(few-shot) 추가 (1~50개 정도)
3. 단순 키워드 기반 RAG (BM25 등 — 단순한 검색부터 시작) 4a. 정보 오류가 지속된다면: 임베딩 기반 고급 RAG 4b. 행동 문제(형식·안전성·관련성)가 지속된다면: 파인튜닝
4. RAG + 파인튜닝 조합으로 더 큰 성능 향상 도모

참고 — 라마 3.1 논문(Dubey et al., 2024)의 관점: 사후 학습의 목적은 새로운 지식을 주입하는 것이 아니라, 모델이 '자신이 무엇을 아는지를 깨닫도록 조정'하는 데 있다.

4. 메모리 병목 현상 — 파인튜닝을 어렵게 만드는 핵심 제약

파인튜닝에 필요한 메모리는 추론보다 훨씬 크다. 이를 이해하면 다양한 파인튜닝 기법이 왜 개발됐는지 명확해진다.

추론에 필요한 메모리. 순방향 패스만 실행되므로 모델 가중치와 활성화 값, KV 벡터가 필요하다.

추론 메모리 ≈ N × M × 1.2
N = 파라미터 수, M = 파라미터당 바이트
활성화 + KV 벡터 = 가중치의 약 20% 추가

예시: 130억 파라미터, 16비트(2바이트)
- 가중치: 13B × 2 = 26GB
- 총 추론 메모리: 26GB × 1.2 = 31.2GB

학습에 필요한 메모리. 역방향 패스(역전파)가 추가된다.

학습 메모리 = 모델 가중치 + 활성화 + 그래디언트 + 옵티마이저 스테이트

옵티마이저별 추가 스테이트:
- SGD: 스테이트 없음 (그래디언트만)
- 모멘텀: 파라미터당 스테이트 1개
- Adam: 파라미터당 스테이트 2개 (트랜스포머에서 가장 일반적)

예시: 130억 파라미터 전체를 Adam으로 학습
- 그래디언트 + 옵티마이저 스테이트: 13B × 3 × 2바이트 = 78GB
- (만약 학습 가능 파라미터가 10억뿐이라면: 1B × 3 × 2 = 6GB)

활성화 메모리 주의. 그래디언트 계산을 위해 활성화를 저장하면 활성화 메모리가 모델 가중치 메모리를 크게 초과할 수 있다. Korthikanti et al. (2022) 논문에 따르면 대형 트랜스포머 모델에서 활성화 메모리가 파라미터+옵티마이저 메모리를 압도하는 사례가 관찰된다.

그래디언트 체크포인팅 (Gradient Checkpointing). 활성화를 저장하는 대신 필요할 때마다 재계산하는 방식으로, 메모리를 줄이는 대신 학습 시간이 늘어나는 트레이드오프가 있다.

핵심 통찰. 학습 가능한 파라미터가 많을수록 메모리가 늘어난다. 학습 가능한 파라미터 수를 줄이는 것이 PEFT의 핵심 아이디어다.

5. 수치 표현 방식과 양자화

모델 가중치 하나를 표현하는 비트 수가 전체 메모리에 직접적인 영향을 미친다.

잘못된 예 — 수치 형식 혼동:

상황: 라마 2를 로드해서 파인튜닝하려 함
잘못된 방법: FP16으로 로드
결과: 성능이 광고된 것보다 훨씬 떨어짐 (라마 2는 BF16으로 공개됨)
올바른 방법: 반드시 지정된 형식(BF16)으로 로드
교훈: 모델을 잘못된 수치 형식으로 로드하면 성능이 크게 저하됨
      (라마 3.1에서도 동일한 BF16/FP16 혼란이 반복됨)

주요 부동소수점 형식:

BF16 vs FP16: 둘 다 16비트지만 BF16은 범위에 더 많은 비트를, 정밀도에는 더 적은 비트를 할당한다. BF16은 FP16에서 표현 불가능한 큰 값도 처리할 수 있지만 정밀도는 낮다. 예: 1234.56789 → FP16은 1235.0(0.035% 오차), BF16은 1232.0(0.208% 오차).

혼합 정밀도 학습 (Mixed Precision Training). 가중치 사본은 높은 정밀도로 유지하지만 그래디언트나 활성화 같은 다른 값은 낮은 정밀도로 유지하는 방식. 자동 혼합 정밀도(AMP) 기능이 ML 프레임워크에서 제공된다.

학습 후 양자화(PTQ). 모델이 완전히 학습된 후에 낮은 정밀도 형식으로 변환하는 방식이다. 가장 널리 사용되며 애플리케이션 개발자에게 특히 적합하다. PyTorch, TensorFlow, Hugging Face Transformers 등 주요 ML 프레임워크가 몇 줄의 코드로 PTQ를 제공한다. 일부 엣지 디바이스는 양자화된 추론만 지원한다(TensorFlow Lite, PyTorch Mobile 등).

양자화 인식 학습(QAT). 학습 중 낮은 정밀도 동작을 시뮬레이션해 낮은 정밀도에서도 품질이 좋은 모델을 만드는 것이 목표다. PTQ보다 더 나은 성능을 낼 수 있지만 추가 연산으로 학습 시간이 늘어난다. Character.AI (2024)는 완전히 INT8로 학습해 학습/서빙 간 정밀도 불일치를 없애고 학습 효율을 향상시켰다.

양자화의 한계. 정밀도를 낮추면 값에 작은 변화가 생기고 이것이 누적되어 성능 저하로 이어질 수 있다. 이론상 1비트가 최소이며, BitNet b1.58(Ma et al., 2024, Microsoft)은 파라미터당 1.58비트만 사용하는 1비트 LLM으로 최대 39억 파라미터 규모에서 라마 2(16비트)와 비슷한 성능을 보였다.

애플의 혼합 양자화(2024). 기기에서 모델을 서빙하기 위해 2비트와 4비트 형식을 혼합해 평균 가중치당 3.5비트를 사용하는 양자화 방식을 도입했다. 엔비디아는 4비트 신경망 시대를 대비해 블랙웰(Blackwell) GPU 아키텍처를 발표했다.

6. 파라미터 효율적 파인튜닝(PEFT) — 적은 파라미터로 비슷한 성능

전체 파인튜닝은 70억 파라미터 모델 기준으로 가중치(14GB)+그래디언트+옵티마이저 스테이트에 총 56GB가 필요해 소비자용 GPU(12~24GB, 고급 최대 48GB)에서는 실행이 어렵다. PEFT는 이 문제를 해결하기 위해 학습 가능한 파라미터를 최소화한다.

전체 파인튜닝 vs 부분 파인튜닝. 전체 파인튜닝은 모든 파라미터를 업데이트하고, 부분 파인튜닝은 일부(예: 마지막 레이어만)만 업데이트한다. 부분 파인튜닝은 메모리는 줄지만, 전체 파인튜닝에 근접한 성능을 내려면 여전히 전체 파라미터의 약 25%를 업데이트해야 해서 파라미터 효율성이 낮다(Houlsby et al., 2019, BERT-Large 기준 GLUE 벤치마크).

PEFT의 등장. Houlsby et al. (2019)이 BERT 모델의 각 트랜스포머 블록에 어댑터 모듈 두 개를 추가해, 학습 가능한 파라미터의 단 3%만으로도 전체 파인튜닝과 성능 차이가 0.4% 이내인 결과를 달성했다. 단점은 어댑터가 추가 레이어를 도입해 순방향 패스에 더 많은 계산 단계를 추가하므로 추론 지연 시간이 늘어난다는 점이다.

PEFT의 두 가지 범주:

1. 어댑터 기반 방법 (부가적 방법): 모델 가중치에 추가 모듈을 붙임
2. LoRA (Hu et al., 2021): 추론 지연 없음, 현재 압도적 1위
3. BitFit (Zaken et al., 2021): LoRA와 비슷한 시기
4. IA3 (Liu et al., 2022): 다중 작업 파인튜닝에 특히 유리, 특정 상황에서 전체 파인튜닝보다 우수

5. LongLoRA (Chen et al., 2023): 컨텍스트 길이 확장에 특화

6. 소프트 프롬프트 기반 방법: 학습 가능한 연속 벡터 토큰을 입력에 추가

7. 프리픽스 튜닝(Li and Liang, 2021): 모든 트랜스포머 레이어 입력 앞에 추가
8. P-튜닝(Liu et al., 2021): 위치 다양성
9. 프롬프트 튜닝(Lester et al., 2021): 임베딩된 입력 앞에만 추가
10. 하드 프롬프트와 달리 사람이 읽을 수 없는 연속 벡터, 역전파로 최적화 가능

huggingface/peft 깃허브 이슈 분석(2024년 10월, 1,000개 이상 공개 이슈): LoRA가 압도적 1위이며, QLoRA가 2위. 소프트 프롬프트는 상대적으로 덜 보편화되어 있지만 관심이 증가하는 추세.

PEFT의 샘플 효율성. PEFT는 파라미터 효율적일 뿐만 아니라 샘플 효율적이기도 하다. 전체 파인튜닝이 눈에 띄는 품질 향상을 위해 수만~수백만 개의 예시가 필요한 반면, 일부 PEFT 방법은 단 수천 개의 예시만으로도 강력한 성능을 낼 수 있다.

CPU 오프로딩. DeepSpeed(Rasley et al., 2020)가 보여준 것처럼 초과 메모리를 CPU로 넘길 수 있다.

7. LoRA — 현재 가장 널리 쓰이는 PEFT 기법

LoRA (Low-Rank Adaptation, Hu et al., 2021)는 기존 어댑터 방식의 추론 지연 시간 증가 문제를 해결하면서 파라미터를 효과적으로 추가한다.

작동 원리. n×m 크기의 가중치 행렬 W가 있을 때 LoRA는 다음과 같이 작동한다:

1단계: 두 저랭크 행렬 A(n×r)와 B(r×m) 구성
       r = LoRA 랭크 (하이퍼파라미터)
       A×B의 곱은 원본 W와 동일한 차원을 가짐

2단계: W' = W + (α/r) × W_AB
       α = 스케일링 계수 (하이퍼파라미터)
       모델에서 W 대신 W' 사용

3단계: 파인튜닝 중에는 A와 B만 업데이트, W는 고정

4단계: 배포 전에 W와 병합 → 추론 시 지연 없음

저랭크 분해(Low-Rank Factorization): 9×9 행렬(81 파라미터)을 9×1과 1×9(합계 18 파라미터)로 분해하면 파라미터가 77% 감소한다. 정보 손실은 있지만 랭크가 높을수록 원본 정보를 더 많이 보존한다.

왜 효과적인가. LLM은 수많은 파라미터를 갖지만 실제로는 매우 낮은 내재적 차원(intrinsic dimension)을 갖는다(Li et al., 2018; Aghajanyan et al., 2020; Hu et al., 2021). 사전 학습이 자연스럽게 모델의 내재적 차원을 줄이며, 더 큰 모델일수록 사전 학습 후 더 낮은 내재적 차원을 갖는 경향이 있다. LoRA 논문에서는 대규모 언어 모델(175B 파라미터, 원문 인용: Hu et al., 2021)을 대상으로 전체 파인튜닝 파라미터의 0.0027%에 해당하는 약 4.7M개만으로도 비슷하거나 더 나은 성능을 달성했다.

저랭크 사전 학습의 한계. ReLORA(Lialin et al., 2023)는 최대 13억 파라미터에서 작동하고, GaLore(Zhao et al., 2024)는 70억 파라미터에서 유망한 성능을 보인다. 하지만 사전 학습이 내재적 차원을 자연스럽게 압축하려면 여전히 충분한 풀랭크 사전 학습이 필요하다는 주장이 있다.

LoRA 구성 — 어디에 적용할 것인가:

LoRA는 어텐션 모듈의 가중치 행렬에 주로 적용한다: 쿼리(Wq), 키(Wk), 값(Wv), 출력 투영(Wo).

대규모 LLM(175B), 학습 가능 파라미터 1,800만 개 제한 시 성능 비교 (원문 인용):
- 단일 행렬 Wq, 랭크 8: WikiSQL 70.4
- 단일 행렬 Wv, 랭크 8: WikiSQL 73.0
- 4개 행렬 모두, 랭크 2: WikiSQL 73.7 (최고)

결론: 쿼리+값 조합이 효과적, 피드포워드 레이어 포함 시 더 좋아짐
데이터브릭스: 모든 피드포워드 레이어에 LoRA 적용 시 가장 큰 성능 향상

LoRA 랭크(r) 선택. 4~64 범위에서 대부분의 사례가 작동한다. r을 특정 값 이상 늘려도 성능이 개선되지 않는 현상이 관찰되며, 일부 연구자는 너무 높은 랭크가 과적합을 일으킬 수 있다고 주장한다. α/r 비율은 보통 1:8에서 8:1 사이로 설정한다.

LoRA의 단점.

• 전체 파인튜닝만큼 완전한 성능이 보장되지 않음
• 모델 아키텍처에 대한 이해와 코딩이 필요해 전체 파인튜닝보다 복잡 (주로 덜 대중적인 모델에서만 문제)
• Hugging Face PEFT, Axolotl, Unsloth, LitGPT 같은 프레임워크가 인기 모델에 대해 별도 설정 없이 지원

LoRA 어댑터의 모듈성. 공개된 파인튜닝된 LoRA 어댑터를 Hugging Face, AdapterHub 같은 플랫폼에서 찾아 재사용할 수 있다. 애플은 30억 파라미터 기본 모델 하나에 여러 LoRA 어댑터를 적용해 아이폰의 서로 다른 기능들에 활용했다.

8. 양자화된 LoRA(QLoRA)와 멀티 LoRA 서빙

QLoRA (Dettmers et al., 2023). 기존 LoRA에서 모델 가중치를 16비트로 저장하던 것을 4비트(NF4, Normal Float 4)로 저장한다. NF4는 사전 학습된 가중치가 대개 중앙값이 0인 정규 분포를 따른다는 사실을 활용해 값을 양자화한다.

QLoRA의 주요 기법:
1. NF4 양자화: 모델 가중치를 4비트로 저장
2. BF16 역양자화: 순전파·역전파 계산 시에만 BF16으로 변환
3. 페이징 최적화(Paged Optimizer): 롱 시퀀스에서 GPU 메모리 부족 시
   CPU-GPU 간 데이터 자동 전송

효과: 650억 파라미터 모델을 단일 48GB GPU에서 파인튜닝 가능
한계: NF4 양자화-역양자화 과정의 추가 비용으로 학습 시간 증가

QLoRA 검증 — 과나코(Guanaco) 모델 시리즈 (2023년 5월 Elo 점수, 원문 인용):

LoRA vs QLoRA — 어댑터 메모리 크기 비교:

LoRA 어댑터가 모델 가중치에 비해 매우 작으므로, LoRA 파라미터를 줄이는 것보다 모델 가중치를 양자화하는 것이 메모리를 훨씬 효과적으로 절약할 수 있다.

LoRA 어댑터 서빙 두 가지 방법.

방법 1 — 어댑터 병합 서빙:
- 추론 전에 LoRA 가중치(A, B)를 원본 모델에 병합(W' = W + AB)
- 추론 시 추가 연산 없음 → 지연 없음
- 서빙할 모델이 하나뿐이라면 이 방법이 일반적으로 더 좋음

방법 2 — 어댑터 분리 서빙 (멀티 LoRA):
- W, A, B를 각각 따로 유지하며 추론 시 병합
- 지연 시간 소폭 증가 but 저장 공간 대폭 절약

저장 공간 비교 (기본 모델 4096×4096, 랭크 8, 고객 100명):
방법 1: 풀랭크 W' 100개 = 16.8M × 100 = 16억 8천만 파라미터
방법 2: 풀랭크 W 1개 + 어댑터(A+B) 100세트
        = 16.8M + 65,536 × 100 = 2,330만 파라미터
저장 공간 절약: 약 72배

방법 2의 추가 장점: 고객 전환 시 전체 가중치 행렬을 새로 로딩할 필요 없이 LoRA 어댑터만 교체하면 되므로 로딩 시간을 크게 줄일 수 있다.

9. 모델 병합 — 여러 모델을 하나로 결합하기

모델 병합은 파인튜닝과 달리 학습 없이 GPU만으로도(또는 GPU 없이도) 실행 가능하다. 병합 후 추가 파인튜닝을 거치면 성능이 더 좋아지는 경우가 많다.

모델 병합의 장점: - 성능: 각기 다른 강점을 가진 모델들을 합쳐 단일 모델로 개선 가능 - 메모리: 여러 모델을 적은 파라미터로 통합해 비용 절약 - 온디바이스 배포: 여러 모델을 하나로 합쳐 메모리 절약, 프라이버시 보호, 인터넷 불필요

모델 병합 vs 앙상블. 앙상블은 각 모델 출력을 결합(요청마다 여러 번 추론, 비용 증가), 병합은 파라미터 자체를 합쳐 단일 모델 생성. Hugging Face 오픈 LLM 리더보드 상위권에 병합 모델들이 즐비하다.

합산 방법 1 — 선형 결합 (Linear Combination):

Merge(A, B) = (WA × A + WB × B) / (WA + WB)

특징:
- 단순하지만 놀라울 정도로 잘 작동함
- 같은 기본 모델에서 파인튜닝된 모델들끼리 결합할 때 특히 효과적
- 모델 수프(Model Soup, Wortsman et al., 2022): 여러 파인튜닝 모델의 가중치를
  통째로 평균내면 추론 시간 그대로에 정확도 향상

작업 벡터(Task Vector = 파인튜닝 모델 - 베이스 모델):
- 작업 벡터를 더하면 능력 결합
- 작업 벡터를 빼면 특정 능력 제거
- 편향 제거나 민감한 기능 삭제에 유용 (Ilharco et al., 2022)

합산 방법 2 — SLERP (Spherical Linear Interpolation, 구면 선형 보간법):

원리: 각 벡터를 구(球) 위의 점으로 보고, 구면 표면의 최단 경로로 병합
보간 인자 0~1: 0.5면 정확히 중간, 0에 가까울수록 첫 번째 벡터 영향 큼

한계: 수학적으로 두 벡터에만 적용 가능
      → 세 개 이상은 순차적으로 수행 (A+B→결과, 결과+C...)

레이어 쌓기 (Depth-wise Scaling / Frankenmerging):

원리: 여러 모델에서 서로 다른 레이어를 가져와 쌓아 올림
특징:
- 새로운 아키텍처와 파라미터 수를 가진 모델 생성 가능
- 보통 추가 파인튜닝 필요 (합산과 달리)
- MoE 모델 생성에 활용 가능

실제 사례:
- 골리앗-120B(alpindale, 2023): 파인튜닝된 라마 2-70B 두 개(Xwin, Euryale)를
  각각 72개 레이어를 가져와 합침 (전체 80개 레이어 중)
- Sparse Upcycling(Komatsuzaki et al., 2022): 사전 학습된 모델로 MoE 생성
  (처음부터 학습하는 것보다 더 나을 수 있음)
- SOLAR 10.7B(Kim et al., 2023): 32레이어 7B 모델로 48레이어 10.7B 모델 생성
- Together AI 에이전트 혼합(Wang et al., 2024): 성능이 아쉬운 오픈 소스 모델 6개로
  일부 벤치마크에서 강력한 범용 모델과 필적하는 성능 달성

연결 (Concatenation):

원리: 파라미터를 합산하는 대신 그냥 이어 붙임
     랭크 r1과 r2인 두 LoRA 어댑터를 연결하면 랭크 r1+r2 어댑터 생성
한계: 개별 모델을 따로 서빙하는 것과 메모리 사용량이 같음
     → 성능 향상 가능하지만 파라미터 증가 대비 효율이 낮아 비추천

불필요한 파라미터 가지치기:

핵심 발견(TIES, Yadav et al., 2023): 작업 벡터 파라미터의 상위 20%만 남겨도
전체를 다 쓸 때와 성능이 거의 비슷함

TIES(Trim, Elect Sign, and merge): 작업 벡터 병합 전 불필요 파라미터 제거
DARE(Drop And REscale): TIES와 비슷한 목적

공통 효과: 최종 병합 모델의 품질 크게 개선
적용 시점: 병합할 모델이 많을수록 가지치기가 더 중요
이유: 한 작업의 불필요한 파라미터가 다른 작업들을 방해할 가능성 증가

연합 학습과의 관계. 모델 병합은 연합 학습(Federated Learning, McMahan et al., 2016)을 수행하는 한 방법이다. 여러 기기가 별도의 데이터로 같은 모델을 독립 학습한 후, 이 버전들을 병합해 하나의 새로운 기본 모델을 만든다.

10. 파인튜닝 전술 — 실무 노하우

기본 모델 선택. 초기 실현 가능성 검토 단계에서는 예산 범위에서 가장 강력한 모델부터 시작하는 것이 좋다. 가장 강한 모델도 괜찮은 결과를 내기 어렵다면 약한 모델은 당연히 더 어렵다.

진행 경로 (Progression Path, 오픈AI 파인튜닝 모범 사례):

1단계: 가장 저렴하고 빠른 모델로 파인튜닝 코드를 테스트 (기능 검증)
2단계: 중간급 모델로 파인튜닝 - 데이터 확인
       데이터 늘림에 따라 학습 손실이 떨어지지 않으면 데이터 문제 의심
3단계: 가장 강한 모델로 실험 - 성능 한계 탐색
4단계: 모든 모델로 학습 진행 - 비용 대비 성능 현황 파악 후 선택

증류 경로 (Distillation Path):

1단계: 소량 데이터 + 가장 강력한 모델 → 최고 성능 모델 생성
2단계: 파인튜닝된 모델로 더 많은 학습 데이터 생성
3단계: 생성된 데이터로 더 저렴한 모델 학습

파인튜닝 방법 선택:

• 처음이라면 LoRA 같은 어댑터 기법으로 시작하고, 나중에 전체 파인튜닝 시도
• 전체 파인튜닝: 보통 최소 수천 개의 예시 필요 (보통 훨씬 더 많이)
• PEFT: 수백 개 정도의 작은 데이터셋으로도 괜찮은 성능 가능
• 여러 모델을 서빙해야 한다면: LoRA 멀티 어댑터 서빙이 훨씬 효율적

핵심 하이퍼파라미터:

학습률 스케줄. 처음에는 더 큰 학습률로 시작해서 나중에는 작은 학습률로 마무리하는 방식. 손실 곡선이 심하게 변동된다면 학습률이 너무 큰 것, 너무 느리게 떨어진다면 학습률이 너무 작은 것이다.

파인튜닝 프레임워크 선택:

• 파인튜닝 API: 가장 쉽지만 지원 모델과 세부 설정이 제한적
• 오픈 소스 프레임워크: LLaMA Factory, Unsloth, Hugging Face PEFT, Axolotl, LitGPT
• 분산 학습: 여러 머신 사용 시 DeepSpeed, PyTorch Distributed, ColossalAI
• 클라우드 연동: 컴퓨팅이 더 필요하다면 클라우드와 매끄럽게 연동되는 프레임워크 선택

핵심 개념 정리

실무 체크리스트

• [ ] 파인튜닝 전에 프롬프트 엔지니어링을 충분히 체계적으로 시도했는가?
• [ ] 오류가 정보 부족(→ RAG 먼저)인지, 행동 방식 문제(→ 파인튜닝)인지 분류했는가?
• [ ] 70억 파라미터 이상 모델이라면 전체 파인튜닝에 필요한 메모리를 계산해봤는가?
• [ ] 소비자용 GPU(12~24GB)라면 PEFT 또는 양자화 기법을 채택했는가?
• [ ] 모델을 로드할 때 지정된 수치 형식(BF16/FP16 등)이 올바르게 설정됐는지 확인했는가?
• [ ] LoRA 랭크(r)와 스케일링 계수(α)의 조합을 실험해봤는가?
• [ ] 수백 개 예시라면 전체 파인튜닝 대신 PEFT부터 시도했는가?
• [ ] 여러 모델을 서빙해야 한다면 멀티 LoRA 서빙을 고려했는가?
• [ ] 학습/검증 손실 곡선으로 과적합 여부와 에폭 수를 모니터링하고 있는가?
• [ ] 파인튜닝 후 다른 작업에서의 성능 저하(정렬 세금)를 측정했는가?
• [ ] 모델 병합을 고려할 때 가지치기(TIES/DARE) 후 병합 여부를 검토했는가?
• [ ] 평가 기준과 파이프라인을 파인튜닝 시작 전에 수립했는가?

연습문제

1. 개념. "파인튜닝은 형식을 위한 것이고, RAG는 사실을 위한 것이다"라는 명제를 텍스트-to-SQL 변환 시스템에 적용해 각각 언제 사용해야 하는지 설명하라. 단, 모델이 덜 유명한 SQL 문법만 지원하는 도구를 처리해야 하는 경우도 포함하라.

2. 계산. 70억 파라미터 모델을 FP16 형식, Adam 옵티마이저로 전체 파인튜닝할 때 필요한 최소 메모리를 계산하라. (가중치 + 그래디언트 + 옵티마이저 스테이트, 활성화 제외) 그리고 동일 모델을 QLoRA(4비트 NF4, 학습 가능 파라미터 1%)로 학습할 때 그래디언트+옵티마이저 메모리가 얼마나 줄어드는지 계산하라.

3. 비교. 기존 어댑터 기반 PEFT 방법(Houlsby et al., 2019)과 LoRA의 핵심 차이는 무엇인가? LoRA가 추론 지연 시간 증가 없이 작동하는 원리를 행렬 분해 관점에서 설명하고, 두 방법의 성능 차이(GLUE 벤치마크 기준)를 비교하라.

4. 분석. 고객 500명에게 각각 맞춤화된 LoRA 파인튜닝 모델을 서빙해야 한다. LoRA 가중치를 병합해서 서빙하는 방식(옵션 1)과 어댑터를 따로 유지하는 방식(옵션 2)의 저장 공간 차이를 계산하라. (기본 모델 4096×4096 가중치 행렬, 랭크 8 가정)

5. 설계. 다국어 지원 고객 서비스 챗봇을 만드는 데, 10개 언어별로 서로 다른 톤과 문체를 적용해야 한다. LoRA 기반 멀티 어댑터 서빙 전략을 설계하고, 이를 SLERP 기반 모델 병합 전략과 비교하여 각각의 장단점을 설명하라. TIES/DARE 가지치기를 어느 시점에 적용해야 하는가?

최신 동향 (2026-05 기준)

최신 동향 (검증 2026-05-21) — 파인튜닝 기초(LoRA·QLoRA)는 책 내용이 유효하다. 최근에는 보상 모델 없이 선호를 직접 최적화하는 DPO·ORPO·GRPO 가 RLHF를 상당 부분 대체하는 추세이며, Unsloth 같은 가속 도구가 널리 쓰인다.

부록 A. 용어 사전

부록 B. 핵심 비교표

파인튜닝 vs RAG — 언제 무엇을 선택하는가

전체 파인튜닝 vs PEFT (LoRA)

양자화 비트 형식 비교

모델 병합 방법 비교

부록 C. 추천 참고 자료

검증된 외부 자료 (Tier 1 공식, 생존 확인 2026-05-21)

부록 D. 연습문제 풀이

1. (파인튜닝: SQL 형식 강제 / RAG: 스키마 정보 주입) Text-to-SQL에서 모델이 유효하지 않은 SQL 문법을 생성하거나 특정 SQL 패턴을 일관되게 따르지 못하는 문제는 행동 방식의 문제이므로 파인튜닝이 적합하다. 특히 덜 유명한 도구의 특수 SQL 문법은 인터넷에 예시가 적어 사전 학습에서 충분히 학습되지 않았을 가능성이 높으므로, 해당 SQL 문법 예시 데이터로 파인튜닝하면 효과적이다. 반면 모델이 알지 못하는 테이블 스키마·컬럼명·외래키 관계 때문에 오답을 내놓는 경우는 정보 부족이므로 RAG로 현재 스키마를 컨텍스트에 주입하는 것이 효과적이다. 둘 다 문제라면 RAG부터 시작해 스키마 접근을 해결한 뒤 파인튜닝으로 형식을 다듬는 순서가 권장된다.

2. (전체 파인튜닝 약 84GB, QLoRA는 그래디언트+옵티마이저 약 0.42GB) 70억(7B) 파라미터를 FP16(파라미터당 2바이트)으로 저장하면 가중치에 14GB. Adam 옵티마이저로 전체 파인튜닝 시 그래디언트 14GB + 옵티마이저 스테이트 2개 × 7B × 4바이트(FP32) = 56GB 추가, 총 최소 84GB. QLoRA(학습 가능 파라미터 1% = 7천만 개) 시 그래디언트+옵티마이저: 7천만 × 3 × 2바이트 = 약 0.42GB (200배 이상 절약). 단, 모델 가중치 자체는 4비트 NF4로 약 3.5GB로 추가 절약된다.

3. (LoRA는 추론 시 행렬을 병합해 추가 지연이 없다) Houlsby et al.(2019)의 기존 어댑터 방식은 트랜스포머 레이어 사이에 별도 MLP 모듈을 직렬로 삽입하므로 추론 시마다 추가 연산이 발생해 지연 시간이 늘어난다. LoRA는 원본 가중치 행렬 W를 고정하고 두 저랭크 행렬 A(n×r)와 B(r×m)만 학습한다. 배포 전에 W' = W + (α/r) × AB로 가중치를 한 번 병합하면 추론 시에는 단일 행렬 W'만 사용하므로 추가 지연이 전혀 없다. 성능 측면에서 Houlsby et al.은 3% 파라미터로 전체 파인튜닝 대비 0.4% 차이를 달성했고, LoRA는 대규모 LLM에서 0.0027% 파라미터로 유사하거나 더 나은 성능을 달성했다.

4. (옵션 2가 저장 공간 약 169배 절약) 기본 모델 가중치 행렬 하나: 4096×4096 = 16,777,216 파라미터. 옵션 1(병합): 전체 W' 500개 = 16,777,216 × 500 = 83억 8,860만 파라미터. 옵션 2(분리): 기본 W 하나(16,777,216) + 어댑터(4096×8 + 8×4096 = 65,536) × 500개 = 16,777,216 + 32,768,000 = 4,955만 파라미터. 비율: 83,886만 / 4,955만 ≈ 169배 절약. 본문의 100명 기준 72배에서 500명으로 스케일 증가로 절약 배율이 더 커진다.

5. (10개 언어별 LoRA 어댑터 서빙이 적합; SLERP 병합은 스타일 충돌 위험) LoRA 기반 멀티 어댑터 전략에서는 공통 베이스 모델 하나와 언어별 소형 어댑터 10개를 유지하며, 요청이 들어올 때 해당 언어의 어댑터를 동적으로 적용한다. 저장 공간을 크게 절약하고, 새 언어 추가 시 어댑터만 추가하면 되므로 유지보수가 쉽다. SLERP 병합 전략은 두 모델씩 순차 병합(10개라면 9번 반복)해야 하며, 서로 다른 톤·문체가 상충해 특정 언어 품질이 저하될 수 있다. TIES/DARE 가지치기는 병합 직전, 각 언어 작업 벡터에서 불필요한 파라미터(하위 80%)를 먼저 제거한 뒤 병합하면 언어 간 간섭을 최소화할 수 있다. 언어별 품질을 독립적으로 보장해야 한다면 멀티 어댑터 서빙이 더 안전한 선택이다.